Paweł Szulc Analityk procesów w Metoda Sp

Paweł Szulc
Analityk procesów w Metoda Sp. z o.o.

Zasady realizacji projektów informatycznych w administracji

Zacznijmy od projektu informatycznego

Projekt informatyczny to przedsięwzięcie, które ma na celu dostarczenie i zastosowanie rozwiązań informatycznych po to, aby wykonywanie czynności i wywiązywanie się z zadań było prostsze. I to jest najważniejsze:
w wyniku zastosowania informatyki powinna następować poprawa jakości życia. Taka sama jak ta, którą daje zastosowanie samochodu do przemieszczania się, czy dźwigu do przenoszenia ciężarów. Dzięki zastosowaniu tego typu narzędzi, w tym rozwiązań informatycznych, możemy działać szybciej, skuteczniej lub w ogóle mamy możliwość wykonywania czynności, których nie dało się zrobić wcześniej. A wszystko po to, żeby nasze usługi i produkty można było dostarczać zewnętrznemu otoczeniu taniej i szybciej, a tym samym, żeby być bardziej konkurencyjnym i osiągać sukcesy w dziedzinie, w której funkcjonujemy. Jeżeli dzięki zastosowaniu informatyki osiągniemy sukcesy, z pewnością będziemy zadowoleni z wyniku projektu (i rozwiązania informatycznego), który doprowadził do tego stanu. Do pełnej satysfakcji brakuje nam jeszcze spełnienia trzech warunków:
1) uzyskania zamówionego rozwiązania w czasie, w którym mieliśmy je otrzymać [CZAS],
2) utrzymania kosztu wykonania projektu na pierwotnie zamierzonym przez nas poziomie [BUDŻET],
3) otrzymania dokładnie tego co zamawialiśmy, co oznacza, że uzyskane rozwiązanie będzie realizować dokładnie to, czego się po nim spodziewaliśmy przy zapewnieniu wymaganej jakości (spełnia nasze wymagania) [ZAKRES].

Niby postulaty proste, ale niezupełnie. Problem w tym, że nie da się wszystkich z wymienionych parametrów w równym stopniu utrzymać na wysokim poziomie. Jeżeli skrócimy czas [CZAS] przy zachowaniu zakresu [ZAKRES], prawdopodobnie odbije się to na budżecie [BUDŻET], ponieważ wówczas należy odpowiednio zwiększyć środki przeznaczone na realizację projektu. Tak samo będzie, jeżeli zwiększymy zakres bez zwiększenia czasu. Jeszcze gorzej, gdy spróbujemy jednocześnie skrócić czas i zwiększyć zakres. Jeśli ustalimy budżet, zwiększymy zakres lub/i skrócimy czas, też będzie źle. Ale nie może być inaczej, bo posługując się metaforą samochodu, jeżeli mamy z góry ograniczoną kwotę na jego zakup, nie możemy dowolnie poszerzać wyposażenia dodatkowego, bez przekroczenia w końcu ustalonego limitu wydatku (chyba że, co zdarza się rzadko, jest on ustalony naprawdę wysoko). Widać jasno, że przy definiowaniu ograniczeń projektowych, czyli elementów [CZAS], [BUDŻET] i [ZAKRES], trzeba zawsze dobrze zastanowić się, na czym naprawdę nam zależy. Nie zawsze musi to być czas uzyskania rozwiązania, nie zawsze też najważniejszy będzie zakres lub budżet. Nasze priorytety mogą być i będą różne dla różnych przedsięwzięć (projektów).
Załóżmy, że w wyniku realizacji projektu, który zakończył się w założonym czasie [CZAS] i nie przekroczył ustalonego budżetu [BUDŻET], otrzymaliśmy rozwiązanie spełniające wszystkie nasze wymagania [ZAKRES] i w dodatku naprawdę nam przydatne. Czy oznacza to pełen sukces? Z punktu widzenia wykonawcy rozwiązania, jego użytkownika oraz zespołu odpowiedzialnego za projekt po stronie zamawiającego, z pewnością tak. Sukces i to duży. Takie przypadki jak opisany, a potwierdzają to statystyki publikowane co pewien czas przez organizacje monitorujące rynek IT, zdarzają się niezwykle rzadko . A co z zamawiającym rozwiązanie - sponsorem?
Zamawiający zainwestował w przedsięwzięcie po to, żeby uzyskać z niego wymierne korzyści, inaczej mówiąc, żeby zarobić więcej niż wyłożył w przyjętej perspektywie czasu. Policzmy. Załóżmy, że inwestycja miała przynosić zyski po 2 latach od zastosowania rozwiązania. Nasze koszty to wydatek poniesiony na opracowanie i dalsze utrzymanie rozwiązania. Zysk to poprawa funkcjonowania organizacji, co można na przykład przeliczyć na większy przychód uzyskany z większej liczby obsłużonych klientów (przypadek firmy handlowej), większej liczby wyprodukowanych towarów (firma produkcyjna), albo na oszczędności uzyskane w wyniku lepszego zaadresowania i śledzenia wydatkowanych środków (przypadek świadczeń wypłacanych przez administrację publiczną). Inwestycja zacznie przynosić zyski po 2 latach, jeżeli zysk uzyskany przez zastosowanie rozwiązania informatycznego w ciągu tych 2 lat zrekompensuje poniesione wydatki. Jeżeli tak będzie, zamawiający (sponsor) będzie mógł również mówić o sukcesie. Natomiast w każdym innym przypadku będzie można mówić o braku uzasadnienia biznesowego dla zastosowanego rozwiązania.

Strony projektu

Z powyższych rozważań wyłaniają się beneficjanci i udziałowcy, czyli strony, które w każdym projekcie można zidentyfikować.
Jedną ze stron jest zamawiający (sponsor), któremu zależy na zwiększeniu zysków i który zastosowanie informatyki traktuje jako inwestycję mającą przynieść wymierne korzyści. Zamawiający w swoim postępowaniu kieruje się rachunkiem ekonomicznym. Dla niego tak naprawdę nie ma znaczenia, czy oczekiwaną poprawę uzyska przez zastosowanie informatyki, zakup odpowiedniej liczby samochodów, czy zwiększenie zatrudnienia. Zawsze wybierze najlepsze rozwiązanie z ekonomicznego punktu widzenia, patrząc na nie z perspektywy przyjętego okresu amortyzacji inwestycji.
Inną stroną jest użytkownik rozwiązania, czyli ten, który bezpośrednio skorzysta na jego zastosowaniu. To właśnie dla niego rozwiązanie ma być przydatne i to jemu ma pomóc wywiązywać się z obowiązków. Użytkownik wie najlepiej, co jest mu potrzebne i to on jest bezpośrednio zainteresowany kształtem powstającego rozwiązania.
Jest też w końcu wykonawca projektu, czyli ten, który ma dostarczyć rozwiązanie informatyczne. Jemu z kolei zależy na wywiązaniu się z podjętych zobowiązań w określonym czasie i zarobieniu wynegocjowanych, satysfakcjonujących pieniędzy. Wykonawca musi dokładnie znać oczekiwania użytkownika, czyli wiedzieć, co ma zrobić.
Nie wszystkie z wymienionych stron są równie silne. Z pewnością zamawiający, jako sponsor projektu jest w tym układzie najsilniejszy, ale nie ma wątpliwości, że nie skonstruuje on zakresu rozwiązania bez udziału użytkownika, a samego rozwiązania bez wykonawcy. Sztuką prowadzenia projektu jest zaspokajanie potrzeb wszystkich zaangażowanych stron, wspólne wypracowywanie najlepszego rozwiązania i znajdowanie kompromisów. Dobra współpraca wszystkich stron jest warunkiem koniecznym, żeby projekt zakończył się sukcesem. Jeżeli tak będzie, z pewnością uda się wybrnąć z pułapek realizacji projektu i ominąć pojawiające się zagrożenia. Jeżeli dobra współpraca nie będzie miała miejsca, szanse na sukces projektu maleją praktycznie do zera . Nie można do tego dopuścić, a jeżeli już na starcie przedsięwzięcia mamy przypuszczenia, że tak może się stać, należy poważnie zastanowić się nad ryzykiem niepowodzenia oraz nad tym, czy w ogóle warto je podejmować.

Rozwiązanie informatyczne

Rozwiązanie informatyczne jest oprogramowaniem (systemem, aplikacją) konstruowanym od początku lub wybranym i zakupionym spośród dostępnych na rynku, albo oprogramowaniem kupionym, uzupełnionym i rozszerzonym. Składową rozwiązania informatycznego może być sprzęt komputerowy (także infrastruktura, np. sieć lokalna), jednak zawsze w pierwszej kolejności trzeba koncentrować się na oprogramowaniu. Jeżeli będziemy wiedzieli, czego chcemy, bez trudu dopasujemy do tego sprzęt. Oprogramowanie, poza tym że nie można go dotknąć, niczym nie różni się od przedmiotów codziennego użytku, które mają pomóc nam funkcjonować, czyli sprawić, żeby życie było prostsze. I to stwierdzenie jest ważne: należy pamiętać, że informatyka nie jest celem samym w sobie.
Nie zawsze warto konstruować rozwiązanie od początku. Jeżeli można odpowiedni produkt kupić, należy to zrobić. Z pewnością będzie to taniej i szybciej aniżeli tworzenie oprogramowania od początku, a w dodatku unikniemy ryzyka związanego z realizacją projektu. Co więcej, gotowy produkt można obejrzeć i wypróbować. Jeśli rynek nie oferuje dokładnie tego, czego potrzebujemy, możemy zastanowić się, czy istnieje produkt, który zaspokaja większość naszych oczekiwań i który można zmodyfikować po zakupie. Jednak modyfikacje nie mogą iść na tyle daleko, żeby koszty ich wykonania nie były porównywalne do kosztów opracowania rozwiązania od początku. Nawiązując do metafory samochodu - albo kupujemy już wyprodukowany samochód w salonie i jesteśmy z niego zadowoleni, albo kupujemy samochód i poddajemy go tunningowi.
Jeżeli taki produkt nie istnieje, możemy zastanowić się nad złożeniem rozwiązania końcowego z kilku gotowych dostępnych na rynku elementów przy założeniu opracowania brakujących fragmentów i połączeń pomiędzy nimi. Czy warto? Trzeba dokładnie policzyć: ile wydamy na gotowe elementy, ile na wykonanie oprogramowania uzupełniającego. Następnie należy porównać to z kosztem opracowania rozwiązania od początku. Dodatkowo trzeba uwzględnić obniżenie ryzyka niepowodzenia projektu przez zmniejszenie jego zakresu (opracowujemy tylko mały fragment pierwotnej całości) i przyspieszenie terminu dostarczenia całego rozwiązania (mniejszy zakres, mniej pracy). I właśnie z tych powodów złożenie produktu z gotowych elementów należy zawsze brać pod uwagę, jako jedno z możliwych rozwiązań. Wracając do samochodu, znajdujemy się w sytuacji, gdy żaden gotowy model nie satysfakcjonuje nas i postanawiamy złożyć nowy wóz rajdowy. Bierzemy najlepszy na rynku silnik od jednego producenta, skrzynię biegów od innego, opony, felgi, układ hamulcowy, zawieszenie od jeszcze innego. Sami konstruujemy podwozie oraz stylową i lekką kompozytową karoserię - jedziemy.
Jeśli sprawdziliśmy, że nie ma na rynku produktu informatycznego, który nas satysfakcjonuje, ani nie możemy go złożyć z wielu gotowych elementów (z powodu braku takich lub dużego kosztu tego typu przedsięwzięcia), pozostaje nam skonstruować rozwiązanie od początku. Zdarza się. W ten sposób kilkanaście lat temu powstał Hummer, najlepsze ponoć auto terenowe na świecie, wykorzystywane z powodzeniem przez armię amerykańską m.in. w czasie wojny w Zatoce Perskiej.

Wymagania

Bez względu na to, w jaki z opisanych wcześniej sposób chcemy uzyskać rozwiązanie, najpierw musimy wiedzieć, o co nam chodzi, czyli czego chcemy.
To chyba każdy wie? "Nie wiesz gdzie tu jest najbliższa cukiernia?" - spytał mnie kolega prowadząc samochód i rozglądając się na boki. "Potrzebujesz cukierni?" - spytałem. - "Nie, potrzebuję ciastka, obiecałem synowi". I tu jest problem. Chciał kupić ciastko, które było dostępne i na mijanej stacji benzynowej, i w najbliższym sklepie spożywczym, ale my szukaliśmy cukierni. Zamiast określić swoje potrzeby, wskazał już rozwiązanie: cukiernia. Dobrze, że dla rozwiązania swojej potrzeby nie zorganizował przetargu, bo co prawda stałby się nie tylko posiadaczem ciastka, ale i cukierni, w której ono powstało.
Sformułowanie oczekiwań nie jest więc takie proste i wymaga od definiującego wielkiej precyzji myślenia, i dużego doświadczenia. Naprawdę trudno wskazać rzeczywistą potrzebę bez odwoływania się do rozwiązania. Powyżej przytoczona historia jest tego przykładem. Zatem skąd wziąć nasze wymagania i jak je sformułować? Najlepiej przyjrzeć się, jak funkcjonuje organizacja, której dotyczy przyszłe rozwiązanie. Sprawdzić, gdzie są największe utrudnienia w pracy i zastanowić się, czy w tych miejscach,
i w kilku innych można zastosować rozwiązanie informatyczne, tak żeby ułatwiało pracę. Jak powinno wyglądać to rozwiązanie, żeby funkcjonowanie organizacji było jak najbardziej usprawnione? Na tym właśnie polega analiza obecnych procesów biznesowych zachodzących w organizacji, tych procesów, które nie uwzględniają jeszcze rozwiązania informatycznego. Tak zidentyfikowany proces najlepiej zapisać, ponieważ będzie to punktem wyjścia do szacowania korzyści z wprowadzenia oprogramowania. Inaczej skąd będziemy wiedzieć, że wprowadzenie rozwiązania informatycznego coś poprawi? Gdy mamy opisany dotychczasowy proces, konstruujemy nowy, który uwzględnia przyszłe oprogramowanie. Znowu całość zapisujemy. Trzeba zwrócić uwagę na to, że nie zmienia się cel procesu zachodzącego w organizacji: jest taki sam, ale zmienia się sposób jego realizacji - teraz zamiast wykonywania niektórych czynności ręcznie używamy narzędzia, w tym przypadku oprogramowania. Jeżeli te wszystkie czynności, czyli cele, które chcemy osiągnąć za pomocą programu, zbierzemy i wszystkie opiszemy, tak żeby wiadomo było, czego oczekujemy od oprogramowania, otrzymamy specyfikację wymagań funkcjonalnych nowej aplikacji. Musimy przy tym powstrzymać się od wypowiadania się na temat wewnętrznej konstrukcji rozwiązania. Uzyskując wymagania wprost z procesu mamy pewność, że są to wszystkie wymagania, jakie są nam potrzebne i tylko takie. Pozostaje do tego dodać m.in. wymagania dotyczące niezawodności i szybkości działania systemu (wymagania niefunkcjonalne) i wówczas dopiero otrzymamy pełny obraz rozwiązania, którego szukamy.
Jako sposób opisu procesów biznesowych warto wziąć pod uwagę zastosowanie przypadków użycia, czyli metodę, którą można w formie niemal identycznej wykorzystać do specyfikowania wymagań funkcjonalnych na system.
Czy jednak coś się stanie, jeżeli nie do końca dokładnie sformułujemy wymagania i specyfikacja nie będzie precyzyjna? W najlepszym przypadku stracimy mnóstwo czasu na wyjaśnianie wątpliwości i braków wykonawcy, który będzie zasypywał nas pytaniami. W najgorszym ryzykujemy, że otrzymamy rozwiązanie, o które nam nie chodziło i które nie jest nam do końca przydatne. Ale to dopiero ujawni się po jego zastosowaniu.

Sposoby realizacji projektu

Spisaliśmy już nasze wymagania (funkcjonalne i jakościowe), mamy też procesy, które pokazują kontekst zastosowania systemu. Wiemy, czego chcemy. Załóżmy, że interesującego nas rozwiązania nie można kupić
w całości lub części na rynku i trzeba opracować je od początku. Co dalej?
Możemy produkt wykonać własnymi siłami. Oznacza to, że będziemy odpowiadać za produkcję, inwestycję, wdrożenie oraz utrzymanie rozwiązania. Wynika stąd, że musimy posiadać wystarczająco dużo osób, projektantów, programistów posiadających odpowiednią wiedzę, w dodatku przyzwoicie opłacanych (by ich utrzymać). Prawdopodobnie musimy mieć też odpowiednie narzędzia do konstrukcji rozwiązania. Jeżeli nie mamy tych zasobów, musimy je pozyskać, jednak należy pamiętać, że dobrego zespołu projektowego nie można utworzyć od ręki. To jest proces, który wymaga czasu.
Wynika stąd, że jeżeli nie jesteśmy firmą specjalizującą się w produkcji oprogramowania, czyli posiadającą odpowiednie zasoby, decyzja o przygotowaniu rozwiązania własnymi siłami łączy się ze zwiększeniem ryzyka niepowodzenia przedsięwzięcia. Poza tym wychodzi na to, że zaczynamy "zawracać sobie głowę" czymś, co wykracza poza obszar naszego zainteresowania i specjalizacji.
Zaletą opisanego rozwiązania jest to, że mamy gwarancję utrzymania produktu (po jego wytworzeniu). Ponieważ sami podjęliśmy się wykonania produktu, nie istnieje ryzyko zerwania współpracy z wykonawcą, ponieważ nie korzystamy z usług firmy zewnętrznej. Jednak nie powinniśmy spodziewać się, że niższy będzie całkowity koszt wytworzenia systemu. Co więcej, przy przekroczeniu założonego budżetu nie będzie z kim negocjować.
Inna możliwość skonstruowania rozwiązania polega na przekazaniu wymagań i procesów jednej, wybranej firmie zewnętrznej i zdanie się na jej umiejętności. W tym przypadku mamy ustalony budżet i czas realizacji, co możemy od wykonawcy egzekwować. Wymóg zapewnienia zasobów znajduje się po jego stronie. Wydaje się, że ryzyko realizacji projektu także, ale nie jest to do końca prawda. Jeżeli wykonawca wycofa się z kontraktu przed jego ukończeniem, co najmniej poniesiemy konsekwencje wynikające z opóźnienia wprowadzenia rozwiązania. Raczej nie odzyskamy też wszystkich poniesionych już wydatków. Dlatego dobra współpraca z wykonawcą leży w naszym interesie. Sukces końcowy przedsięwzięcia jest sukcesem obu stron.
Dodatkową zaletą wyboru jednego, zewnętrznego wykonawcy jest możliwość zdefiniowania wymagań na bardziej ogólnym poziomie, przy założeniu późniejszego dospecyfikowania ich przez wykonawcę we współpracy z nami, czyli zamawiającym. Wykonawca odpowiada za opracowanie rozwiązania, my za inwestycję, wdrożenie i sformułowanie wymagań. Utrzymanie rozwiązania także leży po stronie wykonawcy. Wadą rozwiązania jest uzależnienie się od jednego wykonawcy. Szanse na przejęcie kodu źródłowego w razie rozbieżności oraz dalsze skuteczne utrzymanie i rozwijanie produktu są raczej wątpliwe.
Jeszcze inną możliwością uzyskania żądanego rozwiązania jest homologacja. W przypadku modelu homologacyjnego wymagania pochodzą od zamawiającego, producentem oprogramowania jest zewnętrzny w stosunku do zamawiającego wykonawca, który jest także inwestorem (płaci za opracowanie rozwiązania) oraz rozpowszechnia i utrzymuje system. Wykonawca oprogramowania otrzymuje od zamawiającego pieniądze dopiero, gdy rozwiązanie, które uzyskało świadectwo homologacji, zaczyna być wykorzystywane. Przy czym, w przypadku używania oprogramowania przez jedną organizację będzie to kwota mniejsza niż całkowity koszt wytworzenia rozwiązania i dopiero wykorzystywanie oprogramowania przez wiele organizacji pozwoli producentowi odzyskać zainwestowane pieniądze. Trzeba zwrócić uwagę, że z zalet modelu homologacyjnego nie zawsze można skorzystać. Po pierwsze, musi być dość duży rynek (organizacji), na którym producenci mogą konkurować ze swoim oprogramowaniem (taki jak na przykład rynek Jednostek Organizacyjnych Pomocy Społecznej). Po drugie, trzeba utworzyć właściwy model biznesowy, który pozwoli producentom mieć nadzieję na odzyskanie zainwestowanych pieniędzy i zagwarantuje im równe szanse. W przypadku modelu homologacyjnego oprogramowanie każdego z wykonawców spełnia te same wymagania, a wykonawcy konkurują ze sobą jakością usług oraz dodatkowymi funkcjami realizowanymi przez system. Ponieważ oprogramowanie każdego producenta w tym samym zakresie wspiera funkcjonowanie organizacji jego odbiorcy, łatwo jest mu zrezygnować z jednego i przejść na używanie innego systemu. Producent nie ma monopolu na rozwiązanie, a presja konkurencji powinna podnieść jakość usług.

Składowe projektu

Bez względu na obrany sposób realizacji projektu, w procesie wytworzenia oprogramowania zawsze można wskazać takie składowe, jak analiza potrzeb, specyfikacja wymagań, projektowanie rozwiązania, implementacja, testowanie, wdrożenie. Te składowe mogą być realizowane sekwencyjnie (analiza, specyfikacja, projekt ...), tak jak w podejściu wodospadowym, albo mogą być ciągiem "małych wodospadów", jak podczas realizacji projektu w sposób iteracyjny. Oba podejścia mają swoje wady i zalety, ale czy powinno to nas, jako zamawiającego, interesować? W przypadku gdy nie decydujemy się na wykonanie oprogramowania własnymi siłami, wydaje się, że nie bardzo. Owszem musimy określić nasze wymagania, możemy dodać proces jako ich kontekst i tyle. Teraz oczekujemy produktu, który spełni nasze wymagania. Konstrukcja wewnętrzna systemu nie interesuje nas, tak samo jak nie interesuje nas konstrukcja silnika samochodu, żebyśmy mogli korzystać z niego i być zadowoleni. No, może w przypadku zlecenia opracowania rozwiązania jednemu wykonawcy, powinniśmy jeszcze monitorować postęp prac, żeby na bieżąco identyfikować i zapobiegać pojawiającym się zagrożeniom. To wszystko. To, jak system będzie zbudowany, jakie narzędzia zostaną do wykonania tego zastosowane, jest wewnętrzną sprawą wykonawcy. Nas interesuje [ZAKRES], [BUDŻET] i [CZAS].
Pozostaje więc tylko potwierdzenie, że oprogramowanie, które otrzymujemy rzeczywiście spełnia sformułowane przez nas wymagania, po czym możemy rozpocząć jego wdrożenie. Potwierdzenie oznacza przetestowanie rozwiązania po kątem spełnienia przez nie wymagań użytkownika. Sposób przetestowania oprogramowania oraz dane potrzebne do wykonania testów powinniśmy opracować samodzielnie. Nie ma powodu, żeby obu rzeczy nie przekazać wykonawcy systemu. Jest to przecież ustalony przez nas sposób rozliczenia z wykonania zadania i lepiej, żeby był on tak samo rozumiany przez obie strony. Przekazując wykonawcy przypadki testowe i dane do nich zwiększamy szanse na to, że dostarczone rozwiązanie będzie dobrze sprawdzone przez wykonawcę przynajmniej w zakresie określonym przez przypadki. To oszczędzi nam sporo czasu i ułatwi odbiór oprogramowania. Jednak nic za darmo. Zaprojektowanie testów wymaga pewnego wysiłku i dyscypliny. Dla ułatwienia możemy wykorzystać narzędzia dedykowane do rejestracji przypadków testowych, śledzenia ich wykonania lub w ogóle pozwalające na automatyzację wykonania testów. Pewnym pocieszeniem może być też fakt, że w przypadku zastosowania do opisu wymagań metody przypadków użycia istnieje dobrze określony sposób opracowania na ich podstawie przypadków testowych, co zdecydowanie ułatwia pracę.
Jeżeli potwierdziliśmy spełnienie wymagań przez nowe rozwiązanie i uzgodniliśmy z wykonawcą zasady dalszego jego utrzymania, stoimy przed wdrożeniem. Wdrożenie oprogramowania zawsze wiąże się ze zmianą sposobu funkcjonowania organizacji - zmianą zachodzących w niej procesów. Trzeba o tym pamiętać i nie można tego faktu nie doceniać. Stąd należy odpowiednio dużo uwagi i wsparcia poświęcić ludziom, których zmiany dotyczą. W przeciwnym przypadku staną się oni przeciwnikami nowego rozwiązania i zwiększą ryzyko niepowodzenia przedsięwzięcia. Na pewno nie ma co liczyć na to, że produkt jest tak dobry, że użytkownicy sami do niego się przekonają.

Przykład
Firma, producent z branży FMCG zatrudnia przedstawicieli handlowych, którzy jeżdżą po kraju i sprzedają produkty bezpośrednio w punktach handlowych. Każdy z przedstawicieli działa w następujący sposób (obecny proces): na podstawie zebranych w trakcie poprzednich kursów zamówień oraz na podstawie własnych szacunków określa wielkość zamówienia zbiorczego, które składa w dziale sprzedaży firmy. Przedstawiciel handlowy odbiera zamówiony towar z magazynu i ładuje go na samochód. Aktualizuje rejestr stanu magazynu zwiększając posiadaną liczbę każdego asortymentu o wielkość pobraną z magazynu (rejestr jest prowadzony w postaci zeszytu). Następnie przygotowuje faktury dla odbiorców, którzy zamówili towar wcześniej (faktury wystawiane są ręcznie na drukach samokopiujących) i wyrusza w kurs. Wizytę u każdego z odbiorców przedstawiciel handlowy rozpoczyna od sprawdzenia, czy odwiedzany klient nie posiada zaległych płatności. Jeżeli odbiorca posiada i zgłasza chęć zapłaty, przyjmuje gotówkę (wystawia KP i aktualizuje prowadzony w zeszycie stan kasy). Jeżeli kwota zaległych płatności przekracza ustalony przez firmę limit a odbiorca nie wyraża chęci zapłaty, przedstawiciel handlowy odmawia nowej sprzedaży. W przypadku gdy dostarczany towar był konsekwencją wcześniej złożonego zamówienia, przedstawiciel handlowy dysponuje już przygotowaną fakturą, a w przeciwnym przypadku musi fakturę wypisać (ręcznie na drukach samokopiujących). Jeżeli gotówka była sposobem płatności za fakturę, przyjmuje pieniądze (wystawia KP i aktualizuje prowadzony w zeszycie stan kasy). Towar zostaje wydany, po czym przedstawiciel handlowy aktualizuje rejestr stanu magazynu (rejestr jest prowadzony w postaci zeszytu). Jeżeli odbiorca zgłasza zapotrzebowanie, przedstawiciel handlowy rejestruje zamówienie dotyczące następnych wizyt, zapisując żądane przez odbiorcę towary wraz z przewidywanym terminem realizacji zamówienia (rejestr zamówień prowadzony jest również w postaci zeszytu). Po powrocie do firmy przekazuje do księgowości wystawione faktury i rozlicza się z przyjętej gotówki.
Opisane kroki procesu są powtarzane każdego dnia przez każdego przedstawiciela handlowego.
Szefowie firmy doszli do wniosku, że coś trzeba zmienić, bo w ciągu dnia przedstawiciel handlowy pierwsze 2 godziny pracy spędza na pozyskaniu towaru oraz wypisaniu faktur i w konsekwencji jest w stanie odwiedzić nie więcej niż 10 odbiorców, a jeśli dochodzi do konieczności przepisania już wystawionych faktur (bo odbiorca zmienił wcześniej złożone zamówienie) zaledwie 8. Pomyśleli o zastosowaniu informatyki. W związku z tym, że w firmie nie jest utrzymywany dział IT oraz nie chcąc angażować czasu pracowników firmy w przygotowanie rozwiązania i analizę rynku dostawców, zdecydowali się to zadanie powierzyć firmie zewnętrznej. Wybrana została firma, która specjalizuje się w usprawnianiu procesów biznesowych przez zastosowanie informatyki, sytuująca się pomiędzy odbiorcą końcowym a dostawcami rozwiązań informatycznych, ale nie implementująca rozwiązań i nie posiadająca w swojej ofercie konkretnych gotowych rozwiązań ani technologii. Nazwijmy ją inwestorem zastępczym.
Zadaniem inwestora zastępczego było zaproponowanie nowego procesu sprzedaży realizowanego przez przedstawicieli handlowych, który usunie zidentyfikowane problemy, sformułowanie wymagań opisujących potrzebne oprogramowanie (i sprzęt), zaproponowanie możliwych rozwiązań wraz z rekomendacją najlepszego. Zgromadzony materiał miał posłużyć podjęciu decyzji przez szefów firmy - producenta z branży FMCG. Po wyborze konkretnego rozwiązania inwestor zastępczy miał nadzorować konstrukcję rozwiązania oraz jego wdrożenie. Po stronie zamawiającego ustanowiona została wyłącznie jedna, prowadząca projekt osoba, która kontaktowała się tylko z inwestorem zastępczym. Inwestor zastępczy odpowiedzialny był za ostateczny wynik całego przedsięwzięcia.
Inwestor zastępczy zidentyfikował (i zapisał) obecny proces sprzedaży realizowany przez przedstawicieli handlowych wraz z jego cechami: rejestrowanie zamówień w zeszycie, prowadzenie rejestru stanu magazynu w zeszycie, wypisywanie faktur na drukach samokopiujących, śledzenie stanu kasy w zeszycie, śledzenie należności na kartce, utrzymywanie na kartce listy odbiorców oraz kursów. Analiza procesu wskazała ręczne wypisywanie faktur jako problem, którego rozwiązanie da największe korzyści.
Inwestor zastępczy zaproponował nowy proces, który powinien przynieść maksymalne korzyści: przedstawiciel handlowy rejestruje zamówienie odbiorcy na komputerze osobistym (typu PDA), z którym jeździ w teren, wybierając odbiorcę zamówienia oraz poszczególne asortymenty. Przy konstrukcji zamówienia zbiorczego wskazuje zarejestrowane zamówienia, które chce zrealizować. Do tego dopisuje ilość towaru, który szacuje, że sprzeda bez zamówienia. Zamówienie zbiorcze jest przekazywane do działu sprzedaży w sposób elektroniczny (po podłączeniu komputera przedstawiciela handlowego do sieci podczas wizyty w firmie), a po jego zaakceptowaniu automatycznie uaktualnia się stan magazynu. Przedstawiciel handlowy ładuje zamówiony towar, który już czeka na niego w magazynie i wyrusza w kurs. Należności odbiorcy sprawdzane są na komputerze osobistym przedstawiciela handlowego (dane o płatnościach uaktualniają się podczas przekazywania zamówienia zbiorczego). Jeżeli dostarczany towar był konsekwencją wcześniej złożonego zamówienia, przedstawiciel handlowy wskazuje to zamówienie i korzystając z możliwości programu tworzy fakturę, w przeciwnym przypadku konstruuje fakturę wybierając najpierw odbiorcę, potem kolejno każdy sprzedawany asortyment wraz z określeniem sprzedanej ilości. Faktura jest drukowana przy odbiorcy na drukarce, w którą również przedstawiciel handlowy zostaje wyposażony. Wystawienie faktury automatycznie uaktualnia stan magazynu. Jeżeli przedstawiciel odbiera od klienta gotówkę, za pomocą programu (i komputera osobistego) wystawia dokument KP i prowadzi to do zwiększenia stanu kasy. Informacje o wystawionych fakturach oraz stanie kasy są przekazywane w sposób elektroniczny do działu księgowości podczas przekazywania zamówienia zbiorczego.
Wymagania dotyczące poszukiwanego oprogramowania wynikały wprost z procesu.
Analiza rynku wykonana przez inwestora zastępczego wykazała, że nie istnieje gotowe rozwiązanie, które pozwoliłoby wprowadzić tak zdefiniowany nowy proces. Pozostawało kupić rozwiązanie najbardziej zbliżone i poddać je modyfikacjom lub opracować rozwiązanie od początku. Ze względu na zakres zmian koszt wprowadzenia modyfikacji okazał się porównywalny do kosztu opracowania rozwiązania od początku. Kwoty, które wchodziły w grę, poddawały w wątpliwość istnienie uzasadnienia biznesowego dla proponowanego rozwiązania. Podstawą do szacunków było porównanie korzyści związanych z wprowadzeniem nowego procesu, które wynikały ze wzrostu sprzedaży (z powodu zwiększenia liczby odwiedzanych odbiorców) przy zachowaniu posiadanej liczby przedstawicieli handlowych (i utrzymaniu wydatków ponoszonych na pensje).
Wobec powyższego, inwestor zastępczy zaproponował okrojenie zakresu nowego rozwiązania tak, by można było skorzystać z dostępnego na rynku, gotowego rozwiązania przy założeniu wprowadzenia do niego tylko tych zmian, które da się wykonać jak najniższym kosztem. Okrojenie zakresu doprowadziło do powstania drugiej wersji nowego procesu sprzedaży realizowanego przez przedstawicieli handlowych, która różniła się od pierwszej:
- brakiem możliwości skonstruowania na komputerze osobistym zamówienia zbiorczego
- brakiem możliwości elektronicznej wymiany danych pomiędzy systemem przedstawiciela handlowego a systemem centralnym firmy
- brakiem możliwości utworzenia faktury z wcześniej złożonego zamówienia.

Wydawałoby się, że ograniczenia są znaczące, ale okazało się, że nowy proces (w drugiej wersji) pozwolił osiągnąć 80% korzyści pierwszej wersji procesu za około 50% kosztu potrzebnego do opracowania rozwiązania wspierającego wersję pierwszą. Zostało to osiągnięte przez zastosowanie gotowego rozwiązania oraz skoncentrowanie się na usunięciu "wąskich gardeł" (ręcznego wypisywania faktur), a nie wszystkich problemów. Dodatkowo wykorzystanie produktu dostępnego na rynku obniżyło ryzyko związane z opracowaniem rozwiązania od początku oraz przyspieszyło czas wprowadzenia zmian.
Szefowie firmy - producenta z branży FMCG zaakceptowali propozycję inwestora zastępczego i rozwiązanie zostało zastosowane.
Przytoczony przykład jest uproszczonym opisem przedsięwzięcia zrealizowanego naprawdę. Przyjrzyjmy się mu: zamawiającym (sponsorem) byli szefowie firmy, użytkownikiem przedstawiciele handlowi, a wykonawcą inwestor zastępczy. Dla zamawiającego najważniejszy był stosunek zysku osiągniętego z wprowadzenia rozwiązania do kosztu jego pozyskania [BUDŻET], stąd mógł zrezygnować z części początkowo zdefiniowanych wymagań [ZAKRES]. Duże znaczenie miał dla zamawiającego [CZAS]. Przedsięwzięcie miało uzasadnienie biznesowe, które było możliwe dzięki zastosowaniu koncepcji procesów biznesowych. Rozwiązanie końcowe zostało osiągnięte na drodze modyfikacji produktu dostępnego na rynku, a całe przedsięwzięcie było zrealizowane przez firmę zewnętrzną. W opisanym przykładzie firma zewnętrzna (inwestor zastępczy) przejęła największy z możliwych zakres obowiązków, związanych, z realizacją przedsięwzięcia, pozwalając zamawiającemu operować na poziomie kosztu i zysku z inwestycji, i skoncentrować się na obranej dziedzinie specjalizacji (produkcja i sprzedaż). Zwykle w przypadku większości przedsięwzięć, co nie zawsze jest uzasadnione, rolę inwestora zastępczego pełni własny dział IT firmy. Inwestora zastępczego nie interesowało, jak system będzie zbudowany - co jest "w środku", tylko jego funkcje. W szczególności nie interesował go rodzaj sprzętu, na którym oprogramowanie miało działać. Na podstawie spełnienia wymagań oceniał przydatność rozwiązania oraz odbierał wynik prac.

Projekty informatyczne w administracji

Zastanówmy się, czy projekty informatyczne realizowane w administracji wyróżniają się czymś szczególnym.
W projektach chodzi o to samo, czyli o to, żeby zastosowanie rozwiązania informatycznego poprawiało jakość życia. Tak samo ważne jest właściwe określenie parametrów projektu, czasu, budżetu i zakresu oraz dobre uzasadnienie biznesowe dla jego konstrukcji, chociaż w tym ostatnim przypadku może być czasem trudniej je wskazać. W projektach realizowanych w administracji również można zidentyfikować beneficjantów i udziałowców, czyli strony projektu, zawsze też trzeba mieć na uwadze rozbieżność interesów każdej z nich.
W przypadku administracji publicznej, tak jak każdej innej organizacji, jako sposób pozyskania rozwiązania trzeba brać pod uwagę możliwość zakupienia gotowego oprogramowania, kupienia i dostosowania oraz skonstruowania rozwiązania przez złożenie go z kilku gotowych dostępnych na rynku elementów. Rola precyzyjnego określenia wymagań jest nie do przecenienia, a ich definiowanie można rozpocząć od analizy obecnych procesów i skonstruowania na ich podstawie nowych z uwzględnieniem zastosowania informatyki. Nie ma wątpliwości, że procesy biznesowe zachodzą i że da się je zidentyfikować.
Przy realizacji projektu można zastanawiać się nad każdym z opisanych sposobów realizacji, a gdy już projekt zostanie uruchomiony w procesie wytwarzania oprogramowania, zawsze będzie można wskazać takie same składowe.
A jednak są pewne różnice. Administracja jest źródłem ciekawych i dużych projektów, których realizacja wiąże się z dużymi pieniędzmi. Projekty rozstrzygane są w drodze przetargu. Rzadko kiedy można spotkać tak duże przedsięwzięcia i o takim stopniu rozproszenia jak w administracji.
Daje to mocną pozycję negocjacyjną w kontaktach z potencjalnymi wykonawcami. Z drugiej strony, administracja nie może konkurować z firmami w zakresie płac oferowanych swoim pracownikom. Oznacza to, że mimo wszystko nie powinna być brana pod uwagę możliwość realizacji projektu własnymi siłami. Nawet jeżeli uda się zbudować zespół projektowy, to jego utrzymanie w dłuższej perspektywie czasu będzie bardzo trudne. Zwykle w takich przypadkach administracja jest dla uczestników projektu etapem przejściowym, na którym pozyskują oni nową wiedzę, żeby poprawić swoje argumenty negocjacyjne na drodze dalszej kariery. Żadne zabezpieczenia w rodzaju prób formalnego związania pracownika umową na dłuższy czas nie na wiele się tu zdadzą. Na tym polu administracja skazana jest na porażkę.
Należy więc zrezygnować z pokusy konstruowania rozwiązania we własnym zakresie. Zespół zaangażowany w projekt po stronie administracji należy ograniczyć do minimum. Dla mniejszego zespołu łatwiej znaleźć odpowiednio wysokie środki na uposażenie. Poza tym, mniejszy zespół łatwiej utrzymać. Ludzie ci powinni być odpowiedzialni za sformułowanie wymagań dla nowego rozwiązania, za ich dalsze rozwijanie oraz za określenie kontekstu wykorzystania oprogramowania - zdefiniowanie i utrzymanie procesów biznesowych. Oprócz tego w zakresie odpowiedzialności zespołu powinien leżeć odbiór i akceptacja gotowego rozwiązania poprzez potwierdzenie spełnienia oczekiwanych wymagań. Tyle i nic więcej. Żadnego angażowania się w proces konstrukcji ani utrzymania rozwiązania.
W jak największym stopniu należy oprzeć się na firmach zewnętrznych jako wykonawcach poszczególnych składowych projektów, specjalizujących się w tego typu rozwiązaniach i na bieżąco śledzących zmiany zachodzące na rynku IT. Można nawet pozostawić im spisanie sformułowanych przez zespół wymagań oraz implementację i wykonanie przypadków testowych. W ten sposób rośnie ranga członków zespołu po stronie administracji, a ich rola przesuwa się w stronę "menedżerów rozwiązania" operujących na pograniczu informatyki (wymagania dotyczące systemu) i dziedziny zastosowania (procesy biznesowe). Właśnie na tym poziomie odpowiedzialnych za kształt przyszłego rozwiązania i sterowania dalszym jego rozwojem.

Podsumowanie

Działania podejmowane w administracji, mające na celu podniesienie skuteczności realizacji projektów i zapewnienia jej należnej, silnej pozycji, jako zamawiającego i sponsora przedsięwzięcia, powinny dążyć do jasnego rozdziału kompetencji pomiędzy stronami projektu, przy ustaleniu jednoznacznego sposobu oceny wykonanych prac. Zakres obowiązków pozostający po stronie administracji powinien być ograniczony do niezbędnego minimum, tj.:
- sformułowania procesów biznesowych określających kontekst użycia tworzonego rozwiązania i zwiększających prawdopodobieństwo uzyskania wszystkich wymagań
- sformułowania wymagań opisujących przyszłe rozwiązanie, najlepiej metodą przypadków użycia, która obecnie daje największe szanse na uzyskanie dobrej specyfikacji potrzeb
- opracowania przypadków testowych i przekazania ich wykonawcy systemu jako jednoznacznego sposobu rozliczenia z wykonanych prac (spełnienia wymagań)
- akceptacji gotowego rozwiązania na podstawie potwierdzenia spełnienia wymagań
- zarządzania i optymalizacji opisanych procesów biznesowych i w konsekwencji sterowania ewolucją rozwiązania na poziomie wymagań
- zapewnienia wsparcia użytkownikom i promowanie wśród nich rozwiązania informatycznego.

Przy tak określonym zakresie kompetencji, departamenty informatyki administracji publicznej powinny coraz bardziej upodabniać się do zwykłych firm podlegających regułom gospodarki wolnorynkowej.